Data security service

ABSTRACT

A distributed computing environment utilizes a cryptography service. The cryptography service manages keys securely on behalf of one or more entities. The cryptography service is configured to receive and respond to requests to perform cryptographic operations, such as encryption and decryption. The requests may originate from entities using the distributed computing environment and/or subsystems of the distributed computing environment.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.13/764,963, filed on Feb. 12, 2013, entitled “DATA SECURITY SERVICE,”the content of which is incorporated by reference herein in itsentirety. This application incorporates by reference for all purposesthe full disclosure of co pending U.S. patent application Ser. No.13/764,944, entitled “AUTOMATIC KEY ROTATION,” co-pending U.S. patentapplication Ser. No. 13/764,995, entitled “POLICY ENFORCEMENT WITHASSOCIATED DATA,” co-pending U.S. patent application Ser. No.13/765,020, entitled “DATA SECURITY WITH A SECURITY MODULE,” co-pendingU.S. patent application Ser. No. 13/765,209, entitled “FEDERATED KEYMANAGEMENT,” co-pending U.S. patent application Ser. No. 13/765,239,entitled “DELAYED DATA ACCESS,” and co-pending U.S. patent applicationSer. No. 13/765,283, entitled “SECURE MANAGEMENT OF INFORMATION USING ASECURITY MODULE.”

BACKGROUND

The security of computing resources and associated data is of highimportance in many contexts. As an example, organizations often utilizenetworks of computing devices to provide a robust set of services totheir users. Networks often span multiple geographic boundaries andoften connect with other networks. An organization, for example, maysupport its operations using both internal networks of computingresources and computing resources managed by others. Computers of theorganization, for instance, may communicate with computers of otherorganizations to access and/or provide data while using services ofanother organization. In many instances, organizations configure andoperate remote networks using hardware managed by other organizations,thereby reducing infrastructure costs and achieving other advantages.With such configurations of computing resources, ensuring that access tothe resources and the data they hold is secure can be challenging,especially as the size and complexity of such configurations grow.

BRIEF DESCRIPTION OF THE DRAWINGS

Various embodiments in accordance with the present disclosure will bedescribed with reference to the drawings, in which:

FIG. 1 shows an illustrative diagram representing various aspects of thepresent disclosure in accordance with various embodiments;

FIG. 2 shows an illustrative example of an environment in which variousaspects of the present disclosure may be implemented;

FIG. 3 shows an illustrative example of an environment in which variousaspects of the present disclosure may be implemented and an example flowof information among the various components of the environment inaccordance with at least one embodiment;

FIG. 4 shows example steps of an illustrative process for storingciphertext, in accordance with at least one embodiment;

FIG. 5 shows an illustrative example of an environment in which variousaspects of the present disclosure may be implemented and an example flowof information among the various components of the environment inaccordance with at least one embodiment;

FIG. 6 shows example steps of an illustrative process for responding toa request to retrieve data, in accordance with at least one embodiment;

FIG. 7 shows an illustrative example of an environment in which variousaspects of the present disclosure may be implemented and an example flowof information among the various components of the environment inaccordance with at least one embodiment;

FIG. 8 shows example steps of an illustrative process for responding toa request to store data, in accordance with at least one embodiment;

FIG. 9 shows an illustrative example of an environment in which variousaspects of the present disclosure may be implemented and an example flowof information among the various components of the environment inaccordance with at least one embodiment;

FIG. 10 shows example steps of an illustrative process for responding toa request to retrieve data, in accordance with at least one embodiment;

FIG. 11 shows an illustrative example of an environment in which variousaspects of the present disclosure may be implemented;

FIG. 12 shows an illustrative example of an environment in which variousaspects of the present disclosure may be implemented and an example flowof information among the various components of the environment inaccordance with at least one embodiment;

FIG. 13 shows example steps of an illustrative process for responding toa request to retrieve data, in accordance with at least one embodiment;

FIG. 14 shows example steps of an illustrative process for responding toa request to decrypt data, in accordance with at least one embodiment;

FIG. 15 shows example steps of an illustrative process for obtainingdecrypted data, in accordance with at least one embodiment;

FIG. 16 shows a diagrammatic representation of an example cryptographyservice, in accordance with at least one embodiment;

FIG. 17 shows example steps of an illustrative process for configuringpolicy, in accordance with at least one embodiment;

FIG. 18 shows example steps of an illustrative process for performingcryptographic operations while enforcing policy, in accordance with atleast one embodiment; and

FIG. 19 shows an illustrative example of an environment in which variousembodiments may be implemented.

DETAILED DESCRIPTION

In the following description, various embodiments will be described. Forpurposes of explanation, specific configurations and details are setforth in order to provide a thorough understanding of the embodiments.However, it will also be apparent to one skilled in the art that theembodiments may be practiced without the specific details. Furthermore,well-known features may be omitted or simplified in order not to obscurethe embodiment being described.

Techniques described and suggested herein allow for enhanced datasecurity in environments involving distributed computing resources. Inone example, a distributed computing environment includes one or moredata services which may be implemented by appropriate computingresources. The data services may allow various operations to beperformed in connection with data. As one illustrative example, thedistributed computing environment includes one or more data storageservices. Electronic requests may be transmitted to the data storageservice to perform data storage operations. Example operations areoperations to store data using the data storage service and using thedata storage service to retrieve data stored by the data storageservice. Data services, including data storage services, may alsoperform operations that manipulate data. For example, in someembodiments, a data storage service is able to encrypt data.

Various embodiments of the present disclosure include distributedcomputing environments that include cryptography services that areimplemented using appropriate computing resources. A cryptographyservice may be implemented by a distributed system that receives andresponds to electronic requests to perform cryptographic operations,such as encryption of plaintext and decryption of ciphertext. In someembodiments, a cryptography service manages keys. In response to arequest to perform a cryptographic operation, the cryptography servicemay execute cryptographic operations that use the managed keys. Forexample, the cryptography service can select an appropriate key toperform the cryptographic operation, perform the cryptographicoperation, and provide one or more results of the cryptographicoperation in response to the received request. In an alternativeconfiguration, the cryptography service can produce an envelope key(e.g., a session key that is used to encrypt specific data items) andreturn the envelope key to the system invoking the cryptographicoperations of the service. The system can then use the envelope key toperform the cryptographic operation.

In some embodiments, the cryptography service manages keys for multipletenants of a computing resource service provider. A tenant of thecomputing resource may be an entity (e.g. organization or individual)operating as a customer of the computing resource provider. The customermay remotely and programmatically configure and operate resources thatare physically hosted by the computing resource provider. When acustomer submits a request to the cryptography service to perform acryptographic operation (or when an entity submits a request to thecryptography service), the cryptography service may select a key managedby the cryptography service for the customer to perform thecryptographic operation. The keys managed by the cryptography servicemay be securely managed so that other users and/or data services do nothave access to the keys of others. A lack of access by an entity (e.g.,user, customer, service) to the key of another entity may mean that theentity does not have an authorized way of obtaining the key of the otherand/or that the entity does not have an authorized way of causing asystem that manages the key of the other of using the key at theentity's direction. For example, the cryptography service may managekeys so that, for a customer, other customers both do not have access tothe customer's key(s) and are unable to cause the cryptography serviceto use the customer's key(s) to perform cryptographic operations. Asanother example, the cryptography service may manage keys so that otherservices, such as a data storage service, are unable to cause thecryptography service to use some or all keys to perform cryptographicoperations. Unauthorized access to a key may be prevented by appropriatesecurity measures so that, for example, unauthorized access is difficultor impossible. Difficulty may be due to computational impracticalityand/or due to a need for an unauthorized (e.g., illegal, tortious and/orotherwise disallowed such as a compromise of authorization credentials)to occur for access to be gained. Systems in accordance with the variousembodiments may be configured to ensure an objective measure ofcomputational impracticality to gain access to a key. Such measures maybe, for example, measured in terms of an amount of time, on average, itwould take a computer having a defined unit of computational ability(e.g. certain operations per unit of time) to crack encryptedinformation needed for authorized access to the key.

As noted, a cryptography service may receive requests from variousentities, such as customers of a computing resource provider. Acryptography service may also receive requests from entities internal tothe computing resource provider. For example, in some embodiments, dataservices implemented by the computing resource provider may transmitrequests to a cryptography service to cause the cryptography service toperform cryptographic operations. As one example, a customer maytransmit a request to a data storage service to store a data object. Therequest may indicate that the data object should be encrypted whenstored. The data storage service may communicate a request to acryptography service to perform a cryptographic operation. Thecryptographic operation may be, for example, encryption of a key used bythe data storage service to encrypt the data object. The cryptographicoperation may be encryption of the data object itself. The cryptographicoperation may be to generate an envelope key that the data storageservice can use to encrypt the data object.

Systems in accordance with the various embodiments implement varioussecurity measures to provide enhanced data security. For example, invarious embodiments, the manner in which a cryptography service canutilize keys it manages is limited. For example, in some embodiments, acryptography service is configured to only use a key corresponding to acustomer upon appropriate authorization. If a request to use acustomer's key purportedly originates from the customer (i.e., from acomputing device operating on behalf of the customer), the cryptographyservice may be configured to require that the request be electronically(digitally) signed using appropriate credentials owned by the customer.If the request to use the customer's key originated from another dataservice, the cryptography service may be configured to require that thedata service provide proof that a signed request to the data service hasbeen made by the customer. In some embodiments, for example, the dataservice is configured to obtain and provide a token that serves as proofof an authenticated customer request. Other security measures may alsobe built into a configuration of an electronic environment that includesa cryptography service. For example, in some embodiments, a cryptographyservice is configured to limit key use according to context. As oneillustrative example, the cryptography service may be configured to usea key for encryption for requests from a customer or from a data serviceacting on behalf of the customer. However, the cryptography service maybe configured to only use a key for decryption for requests from thecustomer (but not from another data service). In this manner, if thedata service is compromised, the data service would not be able to causethe cryptography service to decrypt data.

Various security measures may be built into a cryptography serviceand/or its electronic environment. Some security measures may be managedaccording to policies which, in some embodiments, are configurable. Asone example, a cryptography service may utilize an applicationprogramming interface (API) that enables users to configure policies onkeys. A policy on a key may be information that, when processed by acryptography service, is determinative of whether the key may be used incertain circumstances. A policy may, for instance, limit identities ofusers and/or systems able to direct use of the key, limit times when thekey can be used, limit data on which the key can be used to performcryptographic operations on, and provide other limitations. The policiesmay provide explicit limitations (e.g., who cannot use the keys) and/ormay provide explicit authorizations (e.g., who can use the keys).Further, policies may be complexly structured to generally provideconditions for when keys can and cannot be used. When a request toperform a cryptographic operation using a key is received, any policieson the key may be accessed and processed to determine if the requestcan, according to policy, be fulfilled.

FIG. 1 is an illustrative diagram 100 demonstrating various embodimentsof the present disclosure. In an embodiment, a cryptography serviceperforms cryptographic operations which may include application of oneor more calculations in accordance with one or more cryptographicalgorithms. As illustrated in FIG. 1, the cryptography service enables auser or a service to generate plaintext from ciphertext. In an exampleconfiguration the cryptographic service can be used to encrypt/decryptkeys and these keys can be used to encrypt/decrypt data, such as datastored in a data storage service. For example, the cryptography servicereceives a request to generate plaintext from ciphertext encrypted undera key. The cryptography service determines that the requestor is anauthorized entity; decrypts the key using a master key and returns thenow decrypted key to the service, which can generate plaintext from theciphertext using the decrypted key. In another configuration, thecryptography service receives ciphertext and processes the receivedciphertext into plaintext which is provided as a service by thecryptography service. In this example, the ciphertext may be provided tothe cryptography service as part of an electronic request to thecryptography service from an authorized entity, which may be a customerof a computing resource provider that operates the cryptography serviceand/or which may be another service of the computing resource provider.The cryptography service illustrated in FIG. 1 may utilize one or morecryptographically strong algorithms to encrypt data. Suchcryptographically strong algorithms may include, for example, AdvancedEncryption Standard (AES), Blowfish, Data Encryption Standard (DES),Triple DES, Serpent or Twofish, and depending on the specificimplementation selected, may be either asymmetric or symmetric keysystems. Generally, the cryptography service may utilize any encryptionand/or decryption algorithm (cipher) or combination of algorithms thatutilizes data managed by the cryptography service.

As will be discussed below in more detail, the cryptography service canbe implemented in a variety of ways. In an embodiment, the cryptographyservice is implemented by a computer system configured in accordancewith the description below. The computer system may itself comprise oneor more computer systems. For example, a cryptography service may beimplemented as a network of computer systems collectively configured toperform cryptographic operations in accordance with the variousembodiments. Or put another way, the computer system could be adistributed system. In an embodiment, ciphertext is information that hasbeen encrypted using a cryptographic algorithm. In the example of FIG.1, the ciphertext is the plaintext in an encrypted form. The plaintextmay be any information and while the name includes no word text,plaintext and ciphertext may be information encoded in any suitable formand does not necessarily include textual information but it may includetextual information. For example, as illustrated in FIG. 1, plan textand ciphertext comprise sequences of bits. Plaintext and ciphertext mayalso be represented in other ways and generally in any manner by whichencryption and decryption can be performed by a computer system.

FIG. 2 shows an illustrative example of an environment 200 in which acryptography service, such as illustrated in FIG. 1, may be implemented.In the environment of 200, various components operate together in orderto provide secure data related services. In this particular example, theenvironment 200 includes a cryptography service, an authenticationservice, a data service frontend and a data service backend storagesystem. In an embodiment, the cryptography service is configured in theenvironment 200 to perform cryptographic operations, such as byreceiving plaintext from a data service frontend and providingciphertext in return or providing envelope keys to services, so that theservices can use the envelope keys to perform encryption operations. Thecryptography service may perform additional functions, such as describedbelow, such as secure storage of keys for performance of cryptographicoperations, such as converting plaintext into ciphertext and decryptingciphertext into plaintext. The cryptography service may also performoperations involved in policy enforcement, such as by enforcing policyassociated with keys stored therein. Example policies that may beenforced by a cryptography service are provided below. The data servicefrontend in an embodiment is a system configured to receive and respondto requests transmitted over a network from various users. The requestsmay be requests to perform operations in connection with data stored orto be stored in the data service backend storage system. In theenvironment 200, the authentication service, cryptography service, dataservice frontend and data service backend storage system may be systemsof a computing resource provider that utilizes the systems to provideservices to customers represented by the users illustrated in FIG. 2.The network illustrated in FIG. 2 may be any suitable network orcombination of networks, including those discussed below.

The authentication service in an embodiment is a computer systemconfigured to perform operations involved in authentication of theusers. For instance, the data service frontend may provide informationfrom the users to the authentication service to receive information inreturn that indicates whether or not the user requests are authentic.Determining whether user requests are authentic may be performed in anysuitable manner and the manner in which authentication is performed mayvary among the various embodiments. For example, in some embodiments,users electronically sign messages transmitted to the data servicefrontend. Electronic signatures may be generated using secretinformation (e.g., a private key of a key pair associated with a user)that is available to both an authenticating entity (e.g., user) and theauthentication service. The request and signatures for the request maybe provided to the authentication service which may, using the secretinformation, compute a reference signature for comparison with thereceived signature to determine whether the request is authentic. If therequest is authentic, the authentication service may provide informationthat the data service frontend can use to prove to other services, suchas the cryptography service, that the request is authentic, therebyenabling the other services to operate accordingly. For example, theauthentication service may provide a token that another service cananalyze to verify the authenticity of the request. Electronic signaturesand/or tokens may have validity that is limited in various ways. Forexample, electronic signatures and/or tokens may be valid for certainamounts of time. In one example, electronic signatures and/or tokens aregenerated based at least in part on a function (e.g., a Hash-basedMessage Authentication Code) that takes as input a timestamp, which isincluded with the electronic signatures and/or tokens for verification.An entity verifying a submitted electronic signature and/or token maycheck that a received timestamp is sufficiently current (e.g. within apredetermined amount of time from a current time) and generate areference signature/token using for the received timestamp. If thetimestamp used to generate the submitted electronic signature/token isnot sufficiently current and/or the submitted signature/token andreference signature/token do not match, authentication may fail. In thismanner, if an electronic signature is compromised, it would only bevalid for a short amount of time, thereby limiting potential harm causedby the compromise. It should be noted that other ways of verifyingauthenticity are also considered as being within the scope of thepresent disclosure.

The data service backend storage system in an embodiment is a computersystem that stores data in accordance with requests received through thedata service frontend. As discussed in more detail below, the dataservice backend storage system may store data in encrypted form. Data inthe data service backend storage system may also be stored inunencrypted form. In some embodiments, an API implemented by the dataservice frontend allows requests to specify whether data to be stored inthe data service backend storage system should be encrypted. Data thatis encrypted and stored in the data service backend storage system maybe encrypted in various ways in accordance with the various embodiments.For example, in various embodiments, data is encrypted using keysaccessible to the cryptography service, but inaccessible to some or allother systems of the environment 200. Data may be encoded by thecryptography service for storage in the data service backend storagesystem and/or, in some embodiments, data may be encrypted by anothersystem, such as a user system or a system of the data service frontend,using a key that was decrypted by the cryptography service. Examples ofvarious ways by which the environment 200 may operate to encrypt dataare provided below.

Numerous variations of the environment 200 (and other environmentsdescribed herein) are considered as being within the scope of thepresent disclosure. For example, the environment 200 may includeadditional services that may communicate with the cryptography serviceand/or authentication service. For example, the environment 200 mayinclude additional data storage services (which may each comprise afrontend system and a backend system) which may store data in differentways. For instance, one data storage service may provide active accessto data where the data storage service performs data storage services ina synchronous manner (e.g., a request to retrieve data may receive asynchronous response with the retrieved data). Another data storageservice may provide archival data storage services. Such an archivaldata storage service may utilize asynchronous request processing. Forexample, a request to retrieve data may not receive a synchronousresponse that includes the retrieved data. Rather, the archival datastorage service may require a second request to be submitted to obtainthe retrieved data once the archival data storage service is ready toprovide the retrieved data. As another example, the environment 200 mayinclude a metering service which receives information from thecryptography service (and/or other services) and uses that informationto produce accounting records. The accounting records may be used tobill customers for usage of the cryptography service (and/or otherservices). Further, information from the cryptography service mayprovide an indication of how charges should be incurred. For instance,in some instances customers may be provided bills for use of thecryptography service. In other instances, charges for use of thecryptography service may be rolled into usage charges of other services,such as a data service that utilizes the cryptography service as part ofits operations. Usage may be metered and billed in various ways, such asper operation, per period of time, and/or in other ways. Other dataservices may also be included in the environment 200 (or otherenvironments described herein).

In addition, FIG. 2 depicts users interacting with the data servicefrontend. It should be understood that users may interact with the dataservice frontend through user devices (e.g. computers) which are notillustrated in the figure. Further, the users depicted in FIG. 2 (andelsewhere in the figures) may also represent non-human entities. Forexample, automated processes executing on computer systems may interactwith the data service frontend as described herein. As one illustrativeexample, an entity represented by a user in FIG. 2 may be a server that,as part of its operations, uses the data service frontend to storeand/or retrieve data to/from the data service backend storage system. Asyet another example, an entity represented by a user in FIG. 2 may be anentity provided as a service of a computing resource provider thatoperates one or more of the services in FIG. 2. For instance, a user inFIG. 2 may represent a virtual or other computer system of a programexecution service offered by the computing resource provider. Othervariations, including variations of other environments described below,are also considered as being within the scope of the present disclosure.

For example, FIG. 3 shows an illustrative example of an environment 300in which various embodiments of the present disclosure may beimplemented. As with FIG. 2, the environment in FIG. 3 includes anauthentication service, a data service frontend system (data servicefront end), a cryptography service and a data service backend storagesystem. The authentication service, data service frontend, cryptographyservice and data service backend storage system may be configured suchas described above in connection with FIG. 2. For example, users mayaccess the data service frontend through a suitable communicationsnetwork, although such network is not illustrated in the figure. In theexample environment 300 illustrated in FIG. 3, arrows representing aflow of information are provided. In this example, a user transmits aPUT request to the data service frontend. The PUT request may be arequest to store specified data in the data service backend storagesystem. In response to the PUT request, the data service frontend maydetermine whether the PUT request is authentic, that is if the user hassubmitted the request in the manner the requested operation can beperformed in accordance with authentication policy implemented by thesystem.

In FIG. 3, an illustrative example of how such authentication decisionsmay be made is illustrated. In this particular example, the data servicefrontend submits an authentication request to the authenticationservice. The authentication service may use the authentication requestto determine if the PUT request from the user is authentic. If therequest is authentic, the authentication service may provideauthentication proof to the data service frontend. The authenticationproof may be an electronic token or other information that is usable byanother service, such as the cryptography service, to independentlydetermine that an authentic request was received. In one illustrativeexample, the PUT request is transmitted with a signature for the PUTrequest. The PUT request and its signature are provided through theauthentication service, which independently computes what a signatureshould be if authentic. If the signature generated by the authenticationservice matches that signature provided by the user, the authenticationservice may determine that the PUT request was authentic and may provideauthentication proof in response. Determining whether the PUT request isauthentic may also include one or more operations in connection with theenforcement of policy. For example, if the signature is valid but policyotherwise indicates that the PUT request should not be completed (e.g.the request was submitted during a time disallowed by policy), theauthentication service may provide information indicating that therequest is not authentic. (It should be noted, however, that such policyenforcement may be performed by other components of the environment300.) The authentication service may generate the signature, such as byusing a key shared by the authentication service and the user. Theauthentication proof, as noted, may be information from which anotherservice, such as the cryptography service, can independently verify thata request is authentic. For example, using the example of thecryptography service illustrated in FIG. 3, the authentication proof maybe generated based at least in part on a key shared by both theauthentication service and the cryptography service, such as a key thatis inaccessible to other services.

As illustrated in FIG. 3, the data service frontend, upon receipt ofauthentication proof from the authentication service, provides plaintextand authentication proof to the cryptography service. The plaintext andauthentication proof may be provided according to an API call or otherelectronic request to the cryptography service (e.g., an Encrypt APIcall). The cryptography service may analyze the authentication proof todetermine whether to encrypt the plaintext.

It should be noted that additional information may be provided to thecryptography service. For example, an identifier of a key to be used toencrypt the plaintext may be provided as an input parameter to the APIcall from the data service frontend (which, in turn, may have receivedthe identifier from the user). However, it should be noted that anidentifier may not be transmitted to the cryptography service. Forinstance, in various embodiments, it may be otherwise determinable whichkey to use to encrypt the plaintext. For example, informationtransmitted from the data service frontend to the cryptography servicemay include information associated with the user, such as an identifierof the user and/or an organization associated with the user, such as anidentifier of a customer on behalf of which the user has submitted thePUT request. Such information may be used by the cryptography service todetermine a default key to be used. In other words, the key may beimplicitly specified by information that is usable to determine the key.Generally, determination of the key to be used may be performed in anysuitable manner. Further, in some embodiments, the cryptography servicemay generate or select a key and provide an identifier of the generatedor selected key to be used later. Another example API parameter can bean identifier for a master key for the customer account the encryptionoperation is being performed for.

As illustrated in FIG. 3, if the authentication proof is sufficient tothe cryptography service for the plaintext to be encrypted, thecryptography service can perform one or more cryptographic operations.In an embodiment, the one or more cryptographic operations can includean operation to generate an envelope key to be used to encrypt theplaintext. The envelope key can be a randomly generated symmetric key ora private key of a key pair. After the envelope key is generated, thecryptographic service can encrypt the envelope key with the master keyspecified in the API call and cause the encrypted envelope key to bepersistently stored (e.g., by storing the encrypted key in a storageservice or some other durable storage) or discarded. In addition, thecryptographic service can send a plaintext version of the envelope keyas well as and the encrypted envelope key to the data service frontend.The data service can then use the plaintext version of the envelope keyto encrypt the plaintext (i.e., the data associated with the encryptionrequest) and cause the envelope key to be stored in persistent storagein association with an identifier for the master key used to encrypt theenvelope key. In addition, the data service can discard the plaintextversion of the envelope key. As such, in an embodiment after the dataservice discards the plaintext version of the envelope key it will nolonger be able to decrypt the ciphertext.

In an alternative embodiment, the cryptographic operation can involveencrypting the plaintext. For example, the cryptographic serviceencrypts the plaintext and provides ciphertext to the data servicefrontend storage system. The data service frontend may then provide theciphertext to the data service backend storage system for persistentstorage in accordance with its operation. Other information may also betransmitted from the data service frontend to the data service backendstorage system. For example, an identifier of the key used to encryptthe plaintext to generate ciphertext may be provided with the ciphertextfor storage by the data service backend storage system. Otherinformation, such as metadata identifying the user and/or the user'sorganization, may also be provided.

As with all environments described herein, numerous variations areconsidered as being within the scope of the present disclosure. Forexample, the flow of information among the various components of theenvironment 300 may vary from that which is shown. For example,information flowing from one component to another component through anintermediate component (e.g. data from the authentication service to thecryptography service and/or data from the cryptography service to thedata service backend storage system) may be provided directly to itsdestination and/or through other intermediate components of theenvironment 300 (which are not necessarily included in the figure). Asanother example, PUT requests (and, below, GET requests) are providedfor the purpose of illustration. However, any suitable request forperforming the operations described may be used.

FIG. 4 shows an illustrative example of a process 400 which may be usedto store data in a data storage service in accordance with anembodiment. The process 400 may be performed, for example, by the dataservice frontend illustrated in FIG. 3. Some or all of the process 400(or any other processes described herein, or variations and/orcombinations thereof) may be performed under the control of one or morecomputer systems configured with executable instructions and may beimplemented as code (e.g., executable instructions, one or more computerprograms or one or more applications) executing collectively on one ormore processors, by hardware or combinations thereof. The code may bestored on a computer-readable storage medium, for example, in the formof a computer program comprising a plurality of instructions executableby one or more processors. The computer-readable storage medium may benon-transitory.

As illustrated in FIG. 4, the process 400 includes receiving 402 a PUTrequest. The PUT request may be electronically received over a networkand may include information associated with the request, such asinformation required for authentication, such as an electronic signatureof the PUT request. In response to having received the PUT request, theprocess 400 may include submitting 404 an authentication request. Forexample, the system performed in the process 400 may submit (e.g., viaan appropriately configured API call) an authentication request to aseparate authentication service, such as described above in connectionwith FIG. 3. Similarly, a data service frontend that performs its ownauthentication may submit the authentication request to anauthentication module implemented by the data service frontend.Generally, the authentication request may be submitted in any suitablemanner in accordance with the various embodiments.

Upon submission of the authentication request, an authenticationresponse is received 406 by the entity to which the authenticationrequest was submitted 404. For example, referring to FIG. 3, theauthentication service may provide a response to the data servicefrontend that includes proof of the authentication for use by otherservices. Other information, such as an indication of whether or notauthentication was successful, may also be transmitted. A determinationmay be made 408 whether the request is authentic. Authenticity of therequest may depend from one or more factors checked by an entity, suchas by an authentication service, or a combination of entities thatcollectively perform such checks. Authenticity may, for example, requirethat the request provide necessary valid credentials (e.g., anelectronic signature generated by a secret key shared by the checkingentity) and/or that policy allows the request to be fulfilled. From theperspective of a system that submits 404 an authentication request andreceives an authentication response, authenticity may depend from thereceived authentication response. Accordingly, in an embodiment, thedetermination 408 whether the request is authentic may be performedbased at least in part of the received authentication response. Forexample, if authentication was not authentic, the authenticationresponse so indicates and the determination 408 may be made accordingly.Similarly, the response may implicitly indicate that the authenticationrequest is authentic, such as by not including information that would beincluded if the request was authentic. If it is determined 408 that thePUT request is not authentic, then the PUT request may be denied 410.Denying the PUT request may be performed in any suitable manner and maydepend upon the various embodiments in which the process 400 is beingperformed. For example, denying 410, the PUT request may includetransmitting a message to a user that submitted the PUT request. Themessage may indicate that the request was denied. Denying the requestmay also include providing information about why the request was denied,such as an electronic signature not being correct or other reasons thatmay be used for determining how to resolve any issues that resulted inthe PUT request not being authentic or authorized.

If it is determined 408 that the PUT request is authentic andauthorized, then, in an embodiment, the process 400 includes performing412 one or more cryptographic operations that result in the plaintextbeing encrypted. For example, a request (e.g., an appropriatelyconfigured API call) may be submitted to a cryptography service toprovide a key to be used for performing the one or more cryptographicoperations. The request provided to the cryptography service may beprovided with proof of the PUT request being authentic so that thecryptography service can independently determine whether to perform thecryptographic operation (e.g., to encrypt the plaintext and provideciphertext or generate an envelope key that can be used to encrypt theplaintext). However, in various embodiments, authentication proof maynot be provided to the cryptography service and, for example, thecryptography service may operate in accordance with the request that itreceives. For example, if the cryptography service receives a requestfrom the data service frontend, the cryptography service may rely on thefact that the data service frontend has already independently verifiedauthentication of the request. In such an embodiment and otherembodiments, the data service frontend may authenticate itself with thecryptography service to provide an additional layer of security. Thecryptography service may generate or otherwise obtain a key, encrypt theobtained key or otherwise obtain the encrypted key (e.g., from memory),and provide the obtained key and the encrypted obtained key in responseto the request. The obtained key may be encrypted using a key identifiedin the request to the cryptography service. The obtained key may be usedto encrypt the plaintext and, after encrypting the plaintext, theobtained key may be discarded (e.g., irrevocably removed from memory).In alternate embodiment, a system performing the process 400 maygenerate or otherwise obtain the key used to perform the one or morecryptographic operations, provide the obtained key to the cryptographyservice to be encrypted.

In some embodiments, performing the one or more cryptographic operationsmay result in ciphertext being generated. Ciphertext generated as aresult of one or more cryptographic operations may be stored 414 forpossible retrieval at a later time. As noted above, storage of theciphertext may include storage of additional information that wouldenable the decryption of the ciphertext at later time. For instance, theciphertext may be stored with an identifier of a key used to encrypt theplaintext into the ciphertext so that the key having that identifier maylater be used to decrypt the ciphertext to obtain the plaintext. Storageof the ciphertext may also be performed in any suitable manner. Forexample, storage of the ciphertext may be performed by a data servicebackend storage system, such as described above.

FIG. 5, accordingly, shows an illustrative example of an environment 500and the flow of information illustrating how plaintext may be obtained.The environment 500 in this example includes an authentication service,a cryptography service, a data service frontend and a data servicebackend storage system. The authentication service, cryptographyservice, data service frontend and a data service backend storage systemmay be systems such as described above. As illustrated in FIG. 5, thedata service frontend is configured to receive a GET request from a userand provide plaintext in response. In order to do this, the data servicefrontend may also be configured to submit authentication requests to anauthentication service which itself may be configured to, ifappropriate, provide to the data service frontend authentication proof.The data service frontend may also be configured to send a request tothe cryptographic service to cause it to execute one or morecryptographic operations related to decrypting the data. In anembodiment where envelope keys are used, the data service can submit arequest (e.g., an API call) to the cryptographic service that includesor specifies the encrypted envelope key (or an identifier for theencrypted envelope key) authentication proof, and an identifier of themaster key used to encrypt the envelope key to the cryptographicservice. The cryptographic service can determine whether theauthentication proof is sufficient to allow the operation and, if theauthentication proof is sufficient, decrypt the envelope key. Thedecrypted envelope key can be sent back to the data service, which canuse the key to decrypt the encrypted plaintext. The data service canthen discard the decrypted plaintext key.

In an alternative embodiment, the data service frontend may beconfigured to provide the received authentication proof to thecryptography service with ciphertext for the cryptography service todecrypt. The cryptography service may, accordingly, be configured todetermine whether the authentication proof is sufficient to allowdecryption of the ciphertext and, if the authentication proof issufficient, decrypt the ciphertext using an appropriate key (which maybe identified to the cryptography service by the data service frontend),and provide the decrypted ciphertext (plaintext) to the data servicefrontend. To provide ciphertext to the cryptography service, the dataservice frontend may be configured to obtain (e.g., via an appropriatelyconfigured API call) the ciphertext from the data service backendstorage system.

FIG. 6 shows an illustrative example of a process 600 which may be usedto obtain plaintext in accordance with various embodiments. The process600 may be performed, for example, by the data service frontend system(data service frontend) illustrated above in connection FIG. 5, althoughthe process 600 and variations thereof may be performed by any suitablesystem. In an embodiment, the process 600 includes receiving 602 a GETrequest (or other appropriate request) from a user. Receiving the GETrequest may be performed such as described above in connection withother types of requests. Upon receipt 602 of the GET request, anauthentication request may be submitted 604 to an authentication serviceor in any manner such as described above. An authentication responsemay, accordingly, be received. Based at least in part on the receiveauthentication response, a determination may be made 608 whether the GETrequest is authentic. If it is determined 608 that the GET request isnot authentic, the process 600 may include denying 610 the requestwhich, as described above, may be performed in various manners inaccordance with the various embodiments.

If it is determined 608 that the GET request is authentic, the process600 may include retrieving ciphertext from storage. Retrieving 612ciphertext from storage may be performed in any suitable manner. Forexample, referring to the environment 500 discussed above in connectionwith FIG. 5, the data service frontend may submit a request for theciphertext to the data service backend storage system and may receivethe ciphertext in response. Generally, ciphertext may be obtained fromstorage in any suitable manner. Upon receipt of the ciphertext, theprocess 600 may include performing 614 one or more operations relatingto decrypting the ciphertext. For example, in an embodiment, the datastorage service may send a request to the cryptographic service toperform one or more cryptographic operations relating to decrypting theciphertext 614. In one example configuration, the data service can sendthe cryptographic service an API call that includes the encryptedenvelope key (or an identifier for the encrypted envelope key)authentication proof, and an identifier of the master key used toencrypt the envelope key to the cryptographic service. The cryptographicservice can determine whether the authentication proof is sufficient toallow the operation and, if the authentication proof is sufficient,decrypt the envelope key. The decrypted envelope key can be sent back tothe data service, which can use the key to decrypt the encryptedplaintext.

In another configuration, the ciphertext may be provided to acryptography service such as the cryptography service described above inconnection with FIG. 5. Other information may also be provided to thecryptography service such as proof of authentication that can be used bythe cryptography service to determine whether or not to decrypt theciphertext. In addition, in some embodiments, an identifier of a key tobe used by the cryptography service to decrypt the ciphertext may beprovided to the cryptography service. However, in other embodiments, thekey may be implicitly indicated to the cryptography service. Forexample, the cryptography service may use a default key associated witha customer that is indicated to the cryptography service. Generally, anymanner by which the cryptography service can determine which key to useto decrypt the ciphertext may be used.

As illustrated in FIG. 6, after the ciphertext is decrypted, the process600 may include providing 616 a response to the GET request. Providing aresponse to the GET request may be performed in various ways inaccordance with the various embodiments. For example, providing theresponse to the GET request may include providing the plaintext. Inother embodiments, the plaintext may be a key that is used to decryptother encrypted information which is then provided in response to theGET request. Generally, depending on the role of the plaintext in aparticular embodiment of the disclosure, providing a response to the GETrequest may be performed in various ways.

As noted, various embodiments of the present disclosure allow for datato be stored by a data storage service in various ways. FIG. 7 shows anillustrative example of an environment 700 with arrows indicatinginformation flow in accordance with such embodiment. As illustrated inFIG. 7, environment 700 includes an authentication service, acryptography service, a data service frontend and a data service backendstorage system, such as described above. In this particular example, thedata service frontend is a computer system configured to receive PUTrequests from various users. PUT requests may include or specify dataobjects to be stored by a data service backend storage system. PUTrequests may also specify a key identifier for a key to be used toencrypt the data object. The data service frontend may also beconfigured to interact with an authentication service, such as describedabove, in order to provide authentication proof to a cryptographyservice that is operable to receive keys and key identifiers and providein response keys encrypted by the keys identified by the keyidentifiers. The data service frontend may then cause storage in a dataservice backend storage system. The data that may be stored may includea data object encrypted by the key. The data that may be stored may alsoinclude the key encrypted by the key identified by the key identifier.As discussed elsewhere, herein, the encrypted data object and encryptedkey may be stored in different services.

As illustrated in FIG. 7, the data service frontend is configured toprovide encrypted information to the data service backend storage systemfor storage. In this example, the data service frontend is configured toprovide a data object encrypted under a key and the key encrypted underanother key having a KeyID. It should be noted that, for the purpose ofillustration, curly bracket notation is used to denote encryption. Inparticular, information inside of curly brackets is the information thatis encrypted under a key specified in subscript. For example, {DataObject}_(Key) denotes that the data “Data Object” is encrypted under thekey “Key.” It should be noted that a key identifier may also appear insubscript using this curly bracket notation. When a key identifierappears in subscript, the information inside the curly brackets isencrypted under a key identified by the key identifier. For example,{Data Object}_(KeyID) denotes that the data object “Data Object” isencrypted under a key identified by the key identifier “KeyID.”Similarly, {Key}_(KeyID) denotes that the key “Key” is encrypted underthe key identified by the key identifier “KeyID.” In other words, thisdisclosure makes use of both keys and key identifiers in subscript andthe meaning of the subscript should be clear from context. Theciphertext may include additional metadata usable to determine theidentity of the associated decryption key.

FIG. 8 shows an illustrative example of a process 800 which may beperformed to store a data object in a data storage system, such as thedata service backend storage system described above in connection withFIG. 7. The process 800 may be performed by any suitable system, such asby the data service frontend system described above in connection withFIG. 7. In an embodiment, the process 800 includes receiving 802 a PUTrequest for a data object. Receiving the PUT request for the data objectmay be performed in any suitable manner, such as described above. Itshould be noted that the data object can be received in connection withthe request or may be received from another service. For example, therequest may include an identifier for a data object that may be obtainedfrom another service using the identifier. As with other processesdescribed above, the process 800 in an embodiment includes submitting804 an authentication request and receiving 806 an authenticationresponse. The authentication response that was received 806 may be usedto determine 808 whether the PUT request is an authentic request. If itis determined 808 that the PUT request is not authentic, the process 800may include denying 810 the request such as described above. If it isdetermined 808 that the PUT request is authentic, the process 800 mayinclude obtaining 812 a key identifier (KeyID), such as a keyID for amaster key used to encrypt envelope keys. Obtaining 812 the KeyID may beperformed in any suitable manner and the manner in which the KeyID isobtained may vary in accordance with the various embodiments. Forexample, as illustrated in FIG. 7, the PUT request may specify theKeyID. As another example, the identity of the user, or otherwiseassociated with the user, may be used to obtain an identifier or adefault key. As another example, the ciphertext may provide anindication of the associated key ID. As yet another example, one or morepolicy determinations may be used to determine which key identifier toobtain.

In an embodiment, the process 800 also includes generating 814 a key,such as an envelope key. Generating the key may be performed in anysuitable manner by, for example, the cryptographic service or theservice requesting encryption operations from the cryptographic service(e.g., a data storage service). For example, the key may be generatedusing a key derivation function using appropriate input to the keyderivation function. Example key derivation functions include KDF1,defined in IEEE Std 1363 2000, key derivation functions defined in ANSIX9.42, and HMAC-based key derivation functions, such as the HMAC-BasedExtract-and-Expand Key Derivation Function (HKDF) specified in RFC 5869.As another example, the key may be generated by a random or pseudorandom number generator, a hardware entropy source or a deterministicrandom bit generator such as is specified by National Institute ofStandards and Technology Special Publication (NIST SP) 800-90A. Itshould be noted that while FIG. 8 shows the process 800 includinggenerating 814 a key, the key may be obtained in other ways such as byretrieval from storage. In other words, the key may have beenpre-generated.

Continuing with the process 800 illustrated in FIG. 8, in an embodiment,the process 800 includes using 816 the generated key to encrypt a dataobject. For example, in an embodiment where the cryptographic servicegenerates the key, the cryptographic service can provide the key, theKeyID, and an encrypted copy of the key to the data service. Forexample, referring to FIG. 7, the data service frontend may receive theenvelope key and the KeyID for the master key used to encrypt theenvelope key from the cryptography service with any other relevantinformation, such as authentication proof. The plaintext copy of theencryption key may then be used to encrypt the data object. Theplaintext copy of the encryption key can be discarded and the encrypteddata object as well as the encrypted key may then be stored 818. Forexample, referring to FIG. 7, the data service frontend may transmit tothe encrypted data object and the encrypted key to the data servicebackend storage system for storage. In a configuration where the servicegenerates the key, the service can provide the key and the KeyID to thecryptography service. For example, the data service frontend may sendthe envelope key and the KeyID for the master key used to encrypt theenvelope key to the cryptography service with any other relevantinformation, such as authentication proof. The plaintext copy of theencryption key may then be used to encrypt the data object. The servicecan discard the plaintext copy of the encryption key and the encrypteddata object as well as the encrypted key may then be stored. Forexample, referring to FIG. 7, the data service frontend may transmit tothe encrypted data object and the encrypted key to the data servicebackend storage system for storage.

The encrypted data object and the encrypted envelope key may be storedwithout the plaintext version of key, that is, the plaintext key may beinaccessible to the data service backend storage system and one or moreother systems. The key under which the data object is encrypted (e.g.,the master key) may be made inaccessible in any suitable manner. In someembodiments this is achieved by storing it in memory accessible only tothe cryptographic service. In some other embodiments this can beachieved by storing the master key in a hardware or other securitymodule or otherwise under the protection of a hardware or other securitymodule. In some embodiments, the memory location storing the plaintextenvelope key (e.g., memory of the data service) may be allowed to beoverwritten or memory location storing the key may be intentionallyoverwritten to render inaccessible the key to the data service frontend.As another example, the plaintext envelope key may be maintained involatile memory that eventually ceases to store the key. In this manner,the envelope key is only accessible if it is decrypted using a keyidentified by the KeyID or otherwise obtained in an unauthorized manner,such as by cracking the key without the key identified by the KeyID,which may be computationally impractical. In other words, the keyidentified by the KeyID is required for authorized access to the keyunder which the data object is encrypted. Thus, if the data servicebackend storage system of FIG. 7 is compromised, such compromise wouldnot provide access to the unencrypted data object because decrypting thedata object would require access to the key, which is only obtainablethrough decryption using the key identified by the KeyID or throughother ways which are not computationally feasible.

As noted, various embodiments of the present disclosure allow users toboth store data objects and retrieve them in a secure manner. FIG. 9,accordingly, shows an illustrative example of an environment 900 whichmay be used to obtain data objects from storage. As illustrated in FIG.9, the environment 900 includes an authentication service, acryptography service, a data service frontend system and a data servicebackend storage system. The authentication service, cryptographyservice, data service frontend and data service backend storage systemmay be computer systems such as described above. As illustrated in FIG.9, the data service frontend system is configured to receive data objectrequests and provide data objects in response. In order to provide thedata objects in response, the data storage frontend system in thisembodiment is configured to interact with the authentication service,the cryptography service, and the data service backend storage system asillustrated in FIG. 9. For example, in various embodiments, the dataservice frontend system is configured to submit authentication requeststo the authentication service and receives authentication proof inresponse to the requests. As another example, the data service frontendis configured to provide keys encrypted by a key identified by a KeyIDand authentication proof to a cryptography service which is operable todetermine whether to provide the key based, at least in part, on theauthentication proof and, if determined to provide the key, then providethe key to the data service frontend. The data service frontend may alsobe configured to provide other information, such as the KeyID, to thecryptography service. Although, in some embodiments, the KeyID may beimplicitly indicated to the cryptography service, such as throughassociation with other information provided to the cryptography service.It should also be noted that, in some embodiments, the user provides theKeyID to the data service frontend in connection with submittingrequests to the data service frontend. Also, as illustrated in FIG. 9,the data service frontend in an embodiment is configured to request thedata object from the data service backend storage system and receive inresponse the data object encrypted by the key and the key encrypted by akey identified by the KeyID. In some embodiments the cryptographicservice may be operable to refuse to perform decryption of a ciphertextnot generated using a key associated with a specified KeyID.

The data service frontend, in an embodiment, is configured to use thekey received from the cryptography service to decrypt the data objectand provide the decrypted data object to the user. FIG. 10, accordingly,shows an illustrative example of a process 1000 which may be used toprovide the decrypted object in accordance with various embodiments. Theprocess 1000 may be performed by any suitable system such as the dataservice frontend system described in connection with FIG. 9. In anembodiment, the process 1000 includes receiving 1002 a GET request for adata object. Receiving the GET request for the data object may beperformed in any suitable manner such as described above in connectionwith other types of requests. For example, the GET request for the dataobject may include information used to authenticate the request and/orother information. The process 1000, accordingly, in an embodiment, aswith other processes described herein, includes submitting 1004 anauthentication request to an authentication system and receiving 1006 anauthentication response. Submitting the authentication request andreceiving the authentication response may be performed in any suitablemanner, such as described above. The authentication response may be usedto determine 1008 whether or not the GET request is authentic. If it isdetermined 1008 that the GET request is not authentic, the process 1000in an embodiment includes denying 1010 the request. If, however, it isdetermined 1008 that the GET request is authentic, the process 1000 inan embodiment includes retrieving 1012 the encrypted data object and anencrypted key from storage. For example, the data service frontendsystem may obtain the encrypted data object and encrypted key from thedata service backend storage system illustrated above in connection withFIG. 9.

In an embodiment, the process 1000 includes providing 1014 the encryptedenvelope key to a cryptography service. Providing 1014 the encryptedenvelope key to the cryptography service may be performed in anysuitable manner and may be provided with other information, such asauthentication proof that enables the cryptography service to determinewhether to decrypt the encrypted key. In addition, providing 1014 theencrypted envelope key to the cryptography service may include providingan identifier of a key required for authorized decryption of theencrypted envelope key to enable the cryptography service to select akey identified by the identifier from among multiple keys managed by thecryptography service. As noted above, however, keys may be implicitlyidentified. The cryptography service may, accordingly, select anappropriate key and decrypt the encrypted key. Accordingly, in anembodiment, the process 1000 includes receiving 1016 the decryptedenvelope key from the cryptography service. For example, if thecryptography service determines that the authentication proof is validand/or that decryption of the encrypted is allowable according to anyapplicable policies, the cryptography service may provide the decryptedkey to a system attempting to decrypt the data object. The data objectmay then be decrypted 1018 using the decrypted envelope key. Thedecrypted data object may then be provided 1020 to the requestor, suchas the user or other system that submitted the GET request.

In many instances, it is desirable for users (i.e., generally devicesutilizing a cryptography service) to interact directly with thecryptography service. FIG. 11 accordingly shows an illustrative exampleof an environment 1100 which allows for direct user access to acryptography service. In environment 1100, included is an authenticationservice, a data service frontend and a data service backend storagesystem. The authentication service, data service frontend and dataservice backend storage system may be as described above. For example,the data service frontend may be configured to receive and respond torequests from users as illustrated in FIG. 11 over a suitable network.As part of responding to requests from the users over the network, thedata service frontend may also be configured to interact with theauthentication service in order to determine whether user requests areauthentic and/or enforce policy on the requests. The data servicefrontend may also be configured to interact with the data servicebackend storage system as part of fulfilling user requests. Userrequests may include, for example, PUT requests to store data in thebackend storage system and GET requests to retrieve data from the dataservice backend storage system. As above, other requests may also beused in accordance with the various embodiments, such as requests todelete data stored in the data service backend storage system, requeststo update the data stored in the data service backend storage system andthe like.

In the particular example of FIG. 11, in the environment 1100, thecryptography service includes a cryptography service frontend and a dataservice backend. As with the data service frontend, the cryptographyservice frontend is configured to receive and respond to requests fromusers over the network. The cryptography service frontend is alsoconfigured to interact with the authentication service to determinewhether user requests are authentic. Determining whether user requestsare authentic may be performed in a simple manner such as describedabove. It should be noted that, while the cryptography service frontendand the data service frontend interact with the same authenticationservice, the cryptography service frontend and the data service frontendmay interact with different authentication services. Further, thecryptography service frontend may be configured to enforce policy whenresponding to user requests.

The cryptography service frontend, in an embodiment, is configured tointeract with the cryptography service backend. The cryptography servicebackend is configured, in accordance with instructions received from thecryptography service frontend, to perform cryptographic operations.Cryptographic operations include encryption, decryption and hashcalculations and others. The environment 1100 may be used, for example,by users to have plaintext encrypted by the cryptography service so thatthe encrypted data can be stored in the data service backend storagesystem. Examples of such use of the environment 1100 are provided below.In addition, example details of an example cryptography service are alsoprovided below.

Data may be stored in the data service backend storage system in anysuitable manner such as described above. For example, techniques forstoring encrypted data in the backend storage system described above maybe used in the environment 1100. For example, while not illustrated, thedata service frontend may communicate with the cryptography servicefrontend to cause the cryptography service backend to encrypt data whichmay then be stored in the data service backend storage system. Theencrypted data may be a data object and/or an encrypted key that wasused to encrypt a data object. In the environment 1100, data may beplaced into the data service backend storage system in other ways aswell. For example, users may provide plaintext to be encrypted by thecryptography service and may receive ciphertext in response. The usersmay then interact or may submit a request to the data service frontendto request that the ciphertext be stored in the data service backendstorage system. The data service frontend, in this example, may storethe ciphertext in any manner. For instance, the data service frontendand backend storage systems may be configured to be indifferent towhether data is encrypted.

In addition, as with all environments illustrated herein, an additionalfrontend system may be logically located between the users and the dataservice frontend and the cryptography service frontend and possiblyother frontend systems in order to coordinate actions between thesystems. For example, in some embodiments, users may interact with afrontend system that itself interacts with the cryptography servicefrontend and data service frontend so that operations from theperspective of the user are simpler. For example, a user may requestthat a data object be encrypted and stored and a frontend systemresponds to the request by appropriate interactions with thecryptography service frontend and data service frontend. From theperspective of the user, however, such may be performed by a singlerequest. Other variations are also within the scope of the presentdisclosure.

FIG. 12 shows an illustrative example of an environment 1200 which maybe used to implement various embodiments of the present disclosure. InFIG. 12, the environment 1200 is configured to enable users to storeciphertext in a data service backend storage system. As illustrated inFIG. 12, accordingly, the environment 1200 includes a data servicefrontend, a data service backend storage system, an authenticationservice, a cryptography service frontend and a cryptography servicebackend. The data service backend storage system, the data servicefrontend, the authentication service, the cryptography service frontendand the cryptography service backend may be systems such as describedabove in connection with FIG. 11. For example, as illustrated in FIG.12, the data service frontend is configured to receive and respond touser requests and may also be configured to enforce policy on userrequests. The data service frontend, as part of responding to requests,may be configured to submit authentication requests to theauthentication service and receive authentication proof in response inresponse. Upon successful authentication, the data service frontend maybe further configured to interact with the data service backend storagesystem to obtain encrypted data objects and possibly unencrypted dataobjects from the data service backend storage system, which may be thenprovided to a user.

As illustrated in FIG. 12, the cryptography service frontend is alsoconfigured to submit authentication requests to the authenticationservice and receive, in response, authentication proof. Authenticationproof may be used to obtain services from the cryptography servicebackend. For example, the cryptography service frontend may beconfigured to provide ciphertext to the cryptography service backendwith authentication proof and the cryptography service backend may beconfigured to decrypt the ciphertext and provide the ciphertext inreturn. As illustrated in FIG. 12, the ciphertext may be an encryptedkey and the cryptography service backend may decrypt the encrypted keyand provide the decrypted key, that is a plaintext key, to thecryptography service frontend, which is further configured to providethe plaintext key to the user. The user may then use the key to decryptthe encrypted data object received from the data service frontend or todecrypt encrypted data objects stored within the user's domain (e.g.,within a user operated or controlled data center or computer system). Inthis example, the user may have obtained the encrypted key from the dataservice frontend. For example, the user may have submitted a request tothe data service frontend for the data object and/or the key used toencrypt the data object. While illustrated in FIG. 11 as a singlerequest, the separate requests may be made for both the data object andthe key. As illustrated in FIG. 11, the data service frontend may obtainthe encrypted data object and encrypted key from the data servicebackend storage system and provide the encrypted data object andencrypted key to the user.

It should be noted that, as with all environments illustrated herein,variations are considered as being within the scope of the presentdisclosure. For example, FIG. 12 shows a data object encrypted under akey and the key encrypted by another key identified by a key identifierbeing provided to the user. Further levels of encryption may also beused. For example, the data object may be encrypted under a key that isonly accessible to the user (and/or that is not accessible by the othercomponents of the environment 1200). A key used to encrypt the dataobject may also be encrypted under the key that is only accessible tothe user. In this example, unauthorized access to the components of theenvironment 1200 (absent the user) still does not provide access to theunencrypted contents of the data object since access to the user's keyis still required for authorized decryption.

As another example, in the environment 1200 illustrated in FIG. 12, thedata service frontend and the data service backend storage system do nothave access to the plaintext data stored by the data service backendstorage system because the data service frontend and the data servicebackend storage system do not have access to a key needed to decrypt theencrypted data. In some embodiments, however, access may be granted tothe data service frontend and/or the data service backend storagesystem. For instance, in an embodiment, temporary access to the key maybe provided to the data service frontend to enable the data servicefrontend to obtain encrypted data, decrypt the encrypted data, use thedecrypted data for a particular purpose (e.g., indexing), and thendelete or otherwise lose access to the decrypted data. Such actions maybe governed by policy enforced by the data service frontend and/orcryptography service and may require authorization from the user.

FIG. 13 shows an illustrative example of a process 1300 which may beused to obtain an encrypted data object and an encrypted key such asfrom a data service backend storage system such as described above. Theprocess 1300, for example, may be performed by the data service frontendsystem described above in connection with FIG. 12. In an embodiment, theprocess 1300 includes receiving 1302 a GET request for an encrypted dataobject. Receiving the GET request may be performed in any suitablemanner such as by receiving the request via an API call to the dataservice frontend system. As a result of having received the GET request,process 1300 may include submitting 1304 an authentication request andreceiving 1306 an authentication response. Submitting 1304 theauthentication request and receiving 1306 the authentication responsemay be performed in any suitable manner such as described above. Theauthentication response may be used to determine 1308 whether the GETrequest is authentic. If it is determined 1308 that the GET request isnot authentic, the process 1300 may include denying 1310 the GETrequest. Denying 1310 the GET request may be performed in any suitablemanner such as described above. If, however, it is determined 1308 thatthat GET request is authentic, the process 1300 may include providing1312 the encrypted data object with an encrypted key that, whendecrypted, is usable to decrypt the encrypted data object. It should benoted that, as with all processes described herein, numerous variationsare considered as being within the scope of the present disclosure. Forexample, the process 1300 may be configured to respond to the GETrequest, when authentic, by providing the encrypted data object butwithout providing an encrypted key. A requester, that is a user orsystem that submitted the GET request, may obtain the encrypted key inother ways. For example, in some embodiments, users may store encryptedkeys themselves in a data storage system under the user's control. Asanother example, one storage service may store the encrypted data objectand another service may store the encrypted key and the user may obtainthe encrypted data object and encrypted key from the respectiveservices. As another example, another service or a third party to theuser may be used to store encrypted keys and users may obtain encryptedkeys upon request. Generally, any way by which encrypted keys may beprovided may be used.

As illustrated in FIG. 13, the process 1300 may result in an entityhaving been provided a data object and an encrypted key usable todecrypt the data object. In various embodiments, the encrypted key mustbe decrypted in order to decrypt the data object. FIG. 14, accordingly,shows an illustrative example of a process 1400 which may be used toprovide a decrypted key to an entity in need of such a decrypted key inorder to use the decrypted key for decryption of an encrypted dataobject. The process 1400 may be performed by any suitable system such asby the cryptography service frontend system described above inconnection with FIG. 12. In an embodiment, the process 1400 includesreceiving 1402 a decryption to decrypt a key using another key having aspecified KeyID. While the process 1400 is described in connection withdecryption of a key, it should be noted that the process 1400 may beadapted for decryption of data in general. The decryption request may bereceived 1402 in any suitable manner such as described above (e.g., viaan appropriately configured API call). Further, the decryption requestmay be received by any entity appropriate to the context in which theprocess 1400 is being performed. For instance, the decryption requestmay originate from the user or from another system, such as the dataservice frontend discussed above. The decryption request may alsoinclude data (e.g. a key) to be decrypted or a reference thereto. TheKeyID may be specified also in any suitable manner. For example, in someembodiments, the decryption request includes the KeyID or a reference tothe KeyID, that is, information that can be used to determine the KeyID.As discussed above, the KeyID may also be implicitly specified. Forexample, the KeyID may be obtained through association with availabledata such as an identity of a requester that submitted the decryptionrequest. For instance, the key corresponding to the KeyID may be adefault key for the requestor or for the entity on behalf of which therequest was submitted.

The process 1400, in an embodiment, includes submitting 1404 anauthentication request and receiving 1406 an authentication response.Submitting 1404 the authentication request and receiving 1406 theauthentication response may be performed in any suitable manner such asdescribed above. Further, as described above, the receivedauthentication response may be used to determine 1408 whether the GETrequest is authentic. If it is determined 1408 that the GET request isnot authentic, the process 1400 may include denying 1410 the GETrequest. Denying 1410 the GET request may be performed in any suitablemanner such as is described above. If, however, it is determined 1408that the GET request is authentic, the process 1400 may includeaccessing policy information for the specified KeyID and/or for therequester. Policy information may include information including one ormore policies on the KeyID and/or the requester.

In an embodiment, the accessed policy information is used to determine1414 whether any applicable policy allows decryption of the key havingthe specified KeyID. If it is determined 1414 that the policy does notallow decryption of the key specified by the KeyID, the process 1400 mayinclude denying 1410 the GET request such as described above. If,however, it is determined 1414 that policy allows decryption of the keyhaving the specified KeyID, the process 1400 may include decrypting 1416the key using the key identified by the KeyID. Once the key has beendecrypted, using a key having the KeyID, the decrypted key may then beprovided 1418 such as by transmission over a network to the requesterthat submitted the decryption request (or, in some embodiments, anotherauthorized destination).

As illustrated in the environment 1200 discussed above, a user mayobtain encrypted data objects and keys for decrypting the data objectsin various ways. FIG. 15 shows an illustrative example of a process 1500which may be used to obtain plaintext in accordance with variousembodiments. The process 1500 may be performed by any suitable systemsuch as by a system being operated and/or hosted by a user such asdescribed in connection with FIG. 12. Other suitable systems includesystems operating on behalf of users and not necessarily according toreal time user input provided but perhaps according to preprogrammedprocesses.

In an embodiment, the process 1500 includes receiving 1502 ciphertextfrom a data storage service. Requesting 1502 ciphertext from a datastorage service may be performed in any suitable manner such asdescribed above. For example, a system performing the process 1500 mayrequest 1502 ciphertext, using an appropriately configured API call inthe environment 1200 illustrated above in connection with FIG. 12 and/orby the process 1300 described above in connection with FIG. 13.

The process 1500 may also include receiving ciphertext and an encryptedkey. Receiving ciphertext and encrypted key may be performed in anysuitable manner. For example, the ciphertext and encrypted key may bereceived in a response to the request for the ciphertext from a datastorage service. Generally, however, the ciphertext and encrypted keymay be received 1504 in other suitable ways. For example, the request toreceive ciphertext from the data storage service may be an asynchronousrequest and ciphertext may be received 1504 pursuant to another requestthat is subsequently submitted. Further, the ciphertext and encryptedkey may be provided in a single response or may be obtained separatelysuch as by different responses (which may be from the same or fromdifferent systems). As another example, a system performing a process1500 may locally or otherwise store encrypted keys and the encrypted keymay be received from local memory.

In an embodiment, the process 1500 includes requesting decryption of theencrypted key, using a key having a specified KeyID. The KeyID may bespecified in any suitable manner such as described above. Further, itshould be noted that the system performing the process 1500 may be ableto specify the KeyID in any suitable manner. For example, the encryptedkey and/or information provided therewith may specify the KeyID. Asanother example, the system performing the process 1500 may have localor remote access to information that enables determining the KeyID. Alocal or remote database, for instance, may associate data objectidentifiers with key identifiers for keys used to encrypt the dataobjects. Generally, any manner in which the system can be enabled tospecify the KeyID may be used. Further, in some embodiments, the KeyIDneed not be specified, such as when information provided to acryptography service is sufficient to determine the KeyID. The request1506 for decryption of the encrypted key may be performed in anysuitable manner such as in connection with an environment discussedabove in connection with FIG. 12 and/or by performance of the process1400 described above in connection with FIG. 14.

The process 1500, in an embodiment, includes receiving 1508 thedecrypted key. Receiving 1508 the decrypted key may be performed in anysuitable manner. For example, the decrypted key may be received inresponse to a request for decryption of the encrypted key. As anotherexample, the request for decryption of the encrypted key may be anasynchronous request and another request may have been submitted forreceiving the decrypted key. Generally, the decrypted key may bereceived in any suitable manner. Further, as with all informationflowing from one device to another, the passage of information may beperformed using secure channels. For instance, the decrypted key may beonce again encrypted for decryption by an entity receiving the decryptedkey. Generally, any manner of secure communication may be used to passinformation from one entity to another.

Once the decrypted key has been received 1508, the process 1500 mayinclude using 1510 the decrypted key to decrypt 1510 ciphertext andtherefore obtain plaintext. It should be noted that, as with allprocesses described herein, variations are considered as being withinthe scope of the present disclosure. For example, the process 1500 showsa request for ciphertext and a request for decryption of an encryptedkey being performed sequentially. However, as with many operationsdescribed herein in connection with the various processes, operationsneed not be performed sequentially in various embodiments. For example,if a system performing the process 1500 has access to the encrypted keyprior to requesting the ciphertext, or is otherwise able to do so, thesystem may request ciphertext and request decryption of the encryptedkey in parallel or in an order different from that which is illustrated.Other variations are also considered as being within the scope of thepresent disclosure.

As discussed above, various embodiments of the present disclosure aredirected to providing cryptography services. Cryptography services maybe provided by a cryptography service system such as described above.FIG. 16 accordingly shows an illustrative example of a cryptographyservice 1600 in accordance with various embodiments. As illustrated inFIG. 16 and as discussed above, the cryptography service 1600 islogically comprised of a frontend system and a backend system. Both thefrontend system and the backend system may be implemented by one or morecomputer systems configured to perform operations described herein. Forexample, as illustrated in FIG. 16, the frontend system of thecryptography service 1600 implements a request API and a policyconfiguration API. The request API, in an embodiment, is an APIconfigured for requesting cryptographic and other operations to beperformed by the cryptography service. Thus, requests may be made to thefrontend system via the request API in order for such cryptographicoperations to be performed by the cryptography service.

The request API may be configured with the following example,high-level, requests available:

CreateKey(KeyID)

Encrypt(KeyID, Data, [AAD])

Decrypt(KeyID, Ciphertext, [AAD])

Shred(KeyID)

ReKey(Ciphertext, OldKeyID, NewKeyID).

A CreateKey(KeyID) request, in an embodiment, causes the cryptographyservice to create a key identified by the KeyID identified in therequest. Upon receipt of a request, the cryptography service maygenerate a key and associate the key with the KeyID. It should be knownthat KeyID's may be, but are not necessarily unique identifiers. Forinstance, a KeyID may identify a family of keys. For example, in someembodiments, key rotation is performed. Key rotation may involvereplacing keys with other keys to prevent collection of enough decrypteddata to allow practical cracking of a cipher used. If performed at thedirection of an entity different from the cryptography service, use ofthe CreateKey(KeyID) request may cause the cryptography service tocreate a new key to replace an old key identified by the KeyID. The oldkey may remain identified by the KeyID, but may, for instance, be onlyused for decryption (of data that has already been encrypted using theold key) and not for future encryption. As another example, in someembodiments, users of the cryptography service provide their own keyidentifiers and there is a possibility that two different customers mayprovide the same identifier. In such instances, the identifier may notuniquely identify a key or even uniquely identify a family of keys.Various measures may be in place to address this. For example, anidentity or other information associated with a user of the cryptographyservice may be used to identify the proper key or family of keys. Instill other embodiments the cryptographic service may assign a KeyIDrandomly, sequentially, or using any other method.

It should be noted that, when a KeyID does not uniquely identify a key,various systems may be in place to enable proper functionality. Forexample, in various embodiments, a family of keys identified by a KeyIDis finite. If a decryption operation using a key identified by a KeyIDis requested, additional data (e.g., a time stamp of when the encryptionwas performed) may enable determining the proper key to use. In someembodiments, ciphertexts may include information indicating a keyversion. In some embodiments, all possible keys are used to providedifferent decryptions of the data. Since there are a finite number ofkeys, the proper decryption may be selected from those provided. In someembodiments, decryption with a key is performed in a manner that enablesthe cryptographic service to detect that the ciphertext was notgenerated based at least in part on the key, such as by usingauthenticated encryption. Other variations are also considered as beingwithin the scope of the present disclosure.

An Encrypt(KeyID, Data, [AAD]) request may be used to cause thecryptography service to encrypt the specified data using a keyidentified by the KeyID. Additional Authenticated Data (AAD) may be usedfor various purposes and may be data that is not necessarily encrypted,but that is authenticated, e.g. by an electronic signature, a messageauthentication code or, generally, a keyed hash value included with theAAD. In some embodiments, the ciphertext is generated including at leasta portion of the AAD. In some other embodiments the AAD is providedseparately during decryption. In some other embodiments, the AAD isgenerated at decryption time based at least in part on the request andor other metadata such that decryption will only succeed when themetadata passes. In some embodiments, policy may constrain whether acryptographic operation can be performed with respect to particular AAD.Processing of Encrypt(KeyID, Data, [AAD]) requests may require, byprogramming logic and/or policy enforced by the cryptography service,both that the AAD contain particular values and that the AAD beauthentic (e.g., not modified since original transmission). Similarly, aDecrypt(KeyID, Ciphertext, [AAD]) request may be used to cause thecryptography service to decrypt the specified ciphertext using a keyidentified by the KeyID. The AAD in the Decrypt(KeyID, Ciphertext,[AAD]) request may be used such as described above. For instance,processing of the Decrypt(KeyID, Ciphertext, [AAD]) may require, byprogramming logic and/or policy enforced by the cryptography service,both that the AAD contain particular values and that the AAD beauthentic (e.g., not modified since original transmission).

The Shred(KeyID), in an embodiment, may be used to cause thecryptography service to electronically shred a key or family of keysidentified by the specified KeyID. Electronic shredding may includemaking the key no longer accessible. For example, use of theShred(KeyID) request may cause the cryptography system to command one ormore hardware devices to perform a SecureErase operation on one or morekeys identified by the specified KeyID. Generally, the key(s) identifiedby the KeyID may be electronically shredded in any suitable manner, suchas by overwriting data encoding the key with other data (e.g., a seriesof zeros or ones or a random string). If the key(s) are stored encryptedunder a key, the key used to encrypt the keys may be electronicallyshredded, thereby causing a loss of access to the key(s). In someembodiments, the shred operation may cause decrypt operations indicatingthe shredded KeyID to fail at some determined point in the future. Othermanners of securely and permanently destroying any possible access tothe key(s) may be used.

The ReKey(Ciphertext, OldKeyID, NewKeyID) request, in an embodiment, maybe used to cause the cryptography service to encrypt ciphertext under adifferent key. When the cryptography service receives aReKey(Ciphertext, OldKeyID, NewKeyID) request, it may use a keyidentified by the OldKeyID to decrypt the specified ciphertext and thenuse a key identified by the NewKeyID to encrypt the decryptedciphertext. If a key identified by the NewKeyID does not yet exist, thecryptography service may generate a key to use and associate thegenerated key with the specified NewKeyID, such as described inconnection the Create(KeyID) request described above. In someembodiments, the ReKey operation may be operable to cause data to betransferrable between isolated instances of a cryptography service. Insome embodiments, a policy might permit a rekey operation to beperformed on a ciphertext but might not permit the same requestor todirectly decrypt the ciphertext. In some embodiments, ReKey mightsupport rekeying a ciphertext from a key identified by a first KeyIDwithin a first account to a key identified by a KeyID within a secondaccount.

Similarly, the frontend system may implement a policy configuration APIwhich, in an embodiment, enables users to submit requests forconfiguring policies for the performance of cryptographic operations andfor other policy-related operations. Policies may be associated withkeys, groups of keys, accounts, users and other logical entities invarious embodiments. Example policies, which may be configured via thepolicy configuration API, are provided below. In an embodiment, thecryptography service policy configuration API includes the followingrequests:

SetKeyPolicy(KeyID, Policy)

Suspend(KeyID, Public Key)

Reinstate(KeyID, Private Key)

In an embodiment, the SetKeyPolicy(KeyID, Policy) request may be used tocause the cryptography service to store a policy on the key (or familyof keys) identified by the KeyID. A policy may be information that isdeterminative of whether a requested cryptographic operation can beperformed in a particular context. The policy may be encoded in adeclarative access control policy language, such as eXtensinble AccessControl Markup Language (XACML), Enterprise Privacy AuthorizationLanguage (EPAL), Amazon Web Services Access Policy Language, MicrosoftSecPol or any suitable way of encoding one or more conditions that mustbe satisfied for a cryptographic operation to be performed. Policies maydefine what operations can be performed, when the operations can beperformed, which entities can make authorized requests for operations tobe performed, which information is required for a particular request tobe authorized, and the like. In addition, policies may be defined and/orenforced using access control lists, privileges associated with users,and/or operation bitmasks in addition to or instead of the examplesgiven above. Example policies appear below.

In some embodiments the cryptographic service may support a suspendoperation, e.g., using a Suspend(KeyID, Public Key) API call. A suspendoperation enables the customer of the cryptographic service to deny theoperator of the cryptographic service use of or access to a key. Thiscan be useful to customers concerned about covert lawful orders or othercircumstances in which the operator of the cryptographic service mightbe compelled to perform some operation using a key. It may also beuseful to customers that wish to lock particular data and render itinaccessible online. In some embodiments, a suspend operation mightinclude receiving a public key from a customer and encrypting the keyspecified by a given KeyID with the received public key and shreddingthe key specified by the KeyID, such that the provider is not able toaccess the suspended key unless the private key associated with thepublic key is provided, e.g., using a Reinstate(KeyID, Private Key) APICall that both specifies the KeyID and includes the private key. In someother embodiments, a suspend operation might involve encrypting a keyassociated with a specified KeyID using another key managed by thecryptographic service, including without limitation one created for thepurpose of the instant suspend operation. The ciphertext produced bythis operation can be provided to the customer and not retained withinthe cryptographic service. The original key identified by the KeyID canthen be shredded. The cryptographic service may be operable to receivethe provided cipertext and re-import the suspended key. In someembodiments the ciphertext may be generated in a manner that willprevent the cryptographic service from returning a decrypted version tothe customer.

As illustrated in FIG. 16, the cryptography service 1600 includes abackend system that itself comprises various components in someembodiments. For example, the backend system in this example includes arequest processing system which may be a subsystem of the cryptographyservice 1600 that is configured to perform operations in accordance withrequests received through either the request API or the policyconfiguration API. For example, the request processing component mayreceive requests received via the request API and the policyconfiguration API determines whether such requests are authentic and aretherefore fulfillable and may fulfill the requests. Fulfilling therequest may include, for example, performing and/or having performedcryptographic operations. The request processing unit may be configuredto interact with an authentication interface which enables the requestprocessing unit to determine whether requests are authentic. Theauthentication interface may be configured to interact with anauthentication system such as described above. For example, when arequest is received by the request processing unit, the requestprocessing unit may utilize the authentication interface to interactwith an authentication service which may, if applicable, provideauthentication proof that may be used in order to cause a performance ofcryptographic operations.

The backend system of the cryptography service 1600 also, in thisillustrative example, includes a plurality of a security modules(cryptography modules) and a policy enforcement module. One or more ofthe security modules may be hardware security modules although, invarious embodiments, a security module may be any suitable computerdevice configured according to have capabilities described herein. Eachsecurity module in an embodiment stores a plurality of keys associatedwith KeyIDs. Each security module may be configured to securely storethe keys so as to not be accessible by other components of thecryptography service 1600 and/or other components of other systems. Inan embodiment, some or all of the security modules are compliant with atleast one security standard. For example, in some embodiments, thesecurity modules are each validated as compliant with a FederalInformation Processing Standard (FIPS) outlined in FIPS Publication140-1 and/or 140-2, such as one or more security levels outlined in FIPSPublication 140-2. In addition, in some embodiments, each securitymodule is certified under the Cryptogrpahic Module Validation Program(CMVP). A security module may be implemented as a hardware securitymodule (HSM) or another security module having some or all capabilitiesof an HSM. In some embodiments, a validated module is used to bootstrapoperations. In some embodiments, customers can configure some keys thatare stored in and operated on only by validated modules and other keysthat are operated on by software. In some embodiments, the performanceor cost associated with these various options may differ.

The security modules may be configured to perform cryptographicoperations in accordance with instructions provided by the requestprocessing unit. For example, the request processing unit may provideciphertext and a KeyID to an appropriate security module withinstructions to the security module to use a key associated with theKeyID to decrypt the ciphertext and provide in response the plaintext.In an embodiment, the backend system of the cryptography service 1600securely stores a plurality of keys forming a key space. Each of thesecurity modules may store all keys in the key space; however,variations are considered as being within the scope of the presentdisclosure. For example, each of the security modules may store asubspace of the key space. Subspaces of the key space stored by securitymodules may overlap so that the keys are redundantly stored throughoutthe security modules. In some embodiments, certain keys may be storedonly in specified geographic regions. In some embodiments, certain keysmay be accessible only to operators having a particular certification orclearance level. In some embodiments certain keys may be stored in andused only with a module operated by a particular third party providerunder contract with the provider of data storage services. In someembodiments, constructive control of security modules may require thatlawful orders seeking to compel use of keys other than as authorized bythe customer to involve either additional entities being compelled oradditional jurisdictions compelling action. In some embodiments,customers may be offered independent options for the jurisdiction inwhich their ciphertexts are stored and their keys are stored. In someembodiments, security modules storing keys may be configured to provideaudit information to the owner of the keys, and the security modules maybe configured such that the generation and providing of auditinformation not suppressible by the customer. In some embodiments, thesecurity modules may be configured to independently validate a signaturegenerated by the customer such that the provider (e.g., hosting thesecurity modules) is not able to perform operations under keys stored bythe security modules. In addition, some security models may store all ofthe key space and some security modules may store subspaces of the keyspace. Other variations are also considered as being the scope of thepresent disclosure. In instances where different security modules storedifferent subspaces of the key space, the request processing unit may beconfigured such as with a relational table or other mechanism todetermine which security module to instruct to perform cryptographicoperations in accordance with various requests.

In an embodiment, the policy enforcement module is configured to obtaininformation from a request processing unit and determine, based at leastin part on that information, whether the request received through theAPI may be performed. For example, when a request to performcryptographic operation is received through the request API, the requestprocessing unit may interact with the policy enforcement module todetermine whether fulfillment of the request is authorized according toany applicable policy such as policy applicable to a specified KeyID inthe request and/or other policies such as policy associated with therequestor. If the policy enforcement module allows fulfillment of therequest, the request processing unit may, accordingly, instruct anappropriate security module to perform cryptographic operations inaccordance with fulfilling the request.

As with all figures described herein, numerous variations are consideredas being within the scope of the present disclosure. For example, FIG.16 shows the policy enforcement module separate from security modules.However, each security module may include a policy enforcement module inaddition to or instead of the policy enforcement module illustrated asseparate. Thus, each security module may be independently configured toenforce policy. In addition, as another example, each security modulemay include a policy enforcement module which enforces policiesdifferent from policies enforced by a separate policy enforcementmodule. Numerous other variations are considered as being within thescope of the present disclosure.

As discussed above, various policies may be configured by users in orassociation with KeyID such that when requests specify cryptographicoperations being performed in connection with keys corresponding toKeyIDs, policy may be enforced. FIG. 17 provides an illustrative exampleof the process 1700 for updating policy in accordance with variousembodiments. Process 1700 may be performed by any suitable system, suchas by a cryptography service system, such as described above inconnection with FIG. 16. In an embodiment, the process 1300 includesreceiving 1302 a request to update policy for a KeyID. The request maybe received 1302 in any suitable manner. For example, referring to FIG.16 as an example, a request may be received through a policyconfiguration API of the frontend system of the cryptography service1600 described above. The request may be received in any suitablemanner.

The process 1700 in an embodiment includes submitting 1704 anauthentication request and receiving 1706 an authentication response.Submitting 1704 the authentication request and receiving 1706 theauthentication response may be performed in any suitable manner such asdescribed above. Also as described above, the received authenticationresponse may be used to determine 1708 whether the request to updatepolicy for the KeyID is authentic. If it is determined 1708 that thereceived request to update policy for the KeyID is not authentic, therequest may be denied 1710. Denying 1710 the request may be performed inany suitable manner as described above. If, however, it is determined1708 that the received request to update policy for the KeyID isauthentic, the process 1700 may include accessing 1712 policyinformation applicable to the requestor. The policy information may beinformation from which any policy applicable to the requestor may beenforced. For example, within an organization that utilizes acryptography service performed by process 1700, only certain users ofthe organization may be allowed to update policy for KeyIDs. Policyinformation may indicate which users are able to cause the cryptographyservice to update policy for the KeyID and/or even whether the policy isupdatable according to an existing policy. For example, a cryptographyservice may, in some embodiments, receive request to enforce a newpolicy. The cryptography service may check whether any existing policyallows the new policy to be put into place. If the cryptography servicedetermines that the existing policy does not allow enforcement of thenew policy, the request may be denied. Generally, the policy informationmay be any information usable for the enforcement of policy applicableto the requestor.

As illustrated in FIG. 17, the process 1700 includes using the accesspolicy information to determine 1704 whether policy allows the requestedupdate to be performed. If it is determined 1714 that the policy doesnot allow the requested update to be performed, the process 1700 mayinclude denying 1710 the request such as described above. If, however,it is determined 1714 the policy allows the requested update to beperformed, the process 1700 may include updating 1716 policy for theKeyID. Updating policy for the KeyID may include updating policyinformation and having the updated policy being stored in accordancewith or in association with the KeyID. The updated policy informationmay be stored, for example, by a policy enforcement module of thecryptography service such as described above, in connection with FIG.16.

Policy may also be enforced by other components of an electronicenvironment that operate in connection with a cryptography service. Forinstance, referring FIG. 2, discussed above, a cryptography service mayprovide an electronic representation of a policy to the data servicefrontend for the data service frontend to enforce. Such may be useful incircumstances where the data service is better suited to enforce thepolicy. For example, whether an action is allowed by policy may be basedat least in part on information accessible to the data service frontendand not to the cryptography service. As one example, a policy may dependon data stored by the data service backend storage system on behalf of acustomer associated with the policy.

As discussed above, a cryptography service may include various systemsthat allow for the enforcement of policy in accordance with policy onkeys having KeyIDs. FIG. 18, accordingly, shows an illustrated exampleof a process 1800 which may be used to enforce policy. The process 1800may be performed by any suitable system such as by a cryptographyservice system such as described above in connection with FIG. 16. In anembodiment, the process 1800 includes receiving 1802 a request toperform one or more cryptographic operations using a key having a KeyID.While FIG. 18 illustrates the process 1800 as being performed inconnection with a request to perform one or more cryptographicoperations, it should be noted that the process 1800 may be adapted foruse with any request to perform an operation which is not necessarilycryptographic. Example operations are described above.

A determination may be made 1804 whether the received request isauthentic. Determining whether the received request is authentic may beperformed in any suitable manner such as described above. For instance,determining 1804 whether the request is authentic may include submittingan authentication request and receiving an authentication response suchas described above. If it is determined 1804 that the request is notauthentic, the process 1800 may include denying 1806 the request.Denying 1806 the request may be performed in any suitable manner such asdescribed above. If, however, it is determined 1804 that the request isauthentic, the process 1800 may include accessing 1808 policyinformation for the KeyID and/or the requestor. Accessing policyinformation for the KeyID and/or request may be performed in anysuitable manner. For example, accessing policy information for the KeyIDand/or requestor may be performed by accessing the storage policyinformation from one or more storage systems that store such policyinformation. The access policy information may be used to determine 1810whether policy allows the one or more operations to be performed.

If it is determined 1810 that policy does not allow the one or moreoperations to be performed, the process 1800 may include denying 1806the request. If, however, it is determined that policy does allow theone or more operations to be performed, the process 1800 may includeperforming 1812 the requested one or more cryptographic operations. Oneor more results of performance of the one or more cryptographicoperations may be provided 1814 such as provided to the requestor thatsubmitted the received 1802 request to perform the one or morecryptographic operations. In some embodiments information derived atleast in part from allowed requests and or denied requests may beprovided through an audit subsystem.

As discussed, embodiments of the present disclosure allow for flexiblepolicy configuration and enforcement. In some embodiments, policies maystate which services can perform which operations in which contexts. Forexample, a policy on a key may allow a data storage service to cause thecryptography service to perform encryption operations but not decryptionoperations. A policy on a key may also include one or more conditions onthe ciphertext and/or decrypted plaintext. For example, a policy mayrequire that the ciphertext and/or plaintext produce a certain hashvalue (which may be a keyed hash value) before results of an operationbe provided in response to a request. Policies may specify one or morerestrictions and/or permissions that are based at least in part on time,Internet Protocol (IP) from which requests originate, types of contentto be encrypted/decrypted, AAD, and/or other information.

Numerous variations are considered as being within the scope of thepresent disclosure. For example, various embodiments discussed abovediscuss interaction with a separate authentication service. However,components of the environments discussed above may have their ownauthorization components and determining whether requests are authenticmay or may not involve communication with another entity. Further, eachof the environments discussed above are illustrated in connection withparticular operations and capabilities enabled by the environments. Thetechniques discussed above in connection with different environments maybe combined and, generally, environments in accordance with the presentdisclosure may allow for flexible use of the various techniques. As justone example, a cryptography service may be used to, upon request,encrypt both keys and other content, such as non-key data objects. Asanother example, a cryptography service may be configured to receive andrespond to requests from both users (e.g., customers of a computingresource provider) and other services (e.g., data storage services). Insome embodiments, a cryptography service and/or associatedauthentication service may be configured for use with a mobile device toperform encryption of stored data. In some embodiments at least oneunlock pin may be validated by a cryptography service. In still otherembodiments a cryptographic service, as part of an operation, mayreceive information generated by a hardware attestation. In someembodiments a cryptography service may be operable to provide digitalrights management services with respect to content.

FIG. 19 illustrates aspects of an example environment 1900 forimplementing aspects in accordance with various embodiments. As will beappreciated, although a Web-based environment is used for purposes ofexplanation, different environments may be used, as appropriate, toimplement various embodiments. The environment includes an electronicclient device 1902, which can include any appropriate device operable tosend and receive requests, messages or information over an appropriatenetwork 1904 and convey information back to a user of the device.Examples of such client devices include personal computers, cell phones,handheld messaging devices, laptop computers, set-top boxes, personaldata assistants, electronic book readers and the like. The network caninclude any appropriate network, including an intranet, the Internet, acellular network, a local area network or any other such network orcombination thereof. Components used for such a system can depend atleast in part upon the type of network and/or environment selected.Protocols and components for communicating via such a network are wellknown and will not be discussed herein in detail. Communication over thenetwork can be enabled by wired or wireless connections and combinationsthereof. In this example, the network includes the Internet, as theenvironment includes a Web server 1906 for receiving requests andserving content in response thereto, although for other networks analternative device serving a similar purpose could be used as would beapparent to one of ordinary skill in the art.

The illustrative environment includes at least one application server1908 and a data store 1910. It should be understood that there can beseveral application servers, layers, or other elements, processes orcomponents, which may be chained or otherwise configured, which caninteract to perform tasks such as obtaining data from an appropriatedata store. As used herein the term “data store” refers to any device orcombination of devices capable of storing, accessing and retrievingdata, which may include any combination and number of data servers,databases, data storage devices and data storage media, in any standard,distributed or clustered environment. The application server can includeany appropriate hardware and software for integrating with the datastore as needed to execute aspects of one or more applications for theclient device, handling a majority of the data access and business logicfor an application. The application server provides access controlservices in cooperation with the data store, and is able to generatecontent such as text, graphics, audio and/or video to be transferred tothe user, which may be served to the user by the Web server in the formof HyperText Markup Language (“HTML”), Extensible Markup Language(“XML”) or another appropriate structured language in this example. Thehandling of all requests and responses, as well as the delivery ofcontent between the client device 1902 and the application server 1908,can be handled by the Web server. It should be understood that the Weband application servers are not required and are merely examplecomponents, as structured code discussed herein can be executed on anyappropriate device or host machine as discussed elsewhere herein.

The data store 1910 can include several separate data tables, databasesor other data storage mechanisms and media for storing data relating toa particular aspect. For example, the data store illustrated includesmechanisms for storing production data 1912 and user information 1916,which can be used to serve content for the production side. The datastore also is shown to include a mechanism for storing log data 1914,which can be used for reporting, analysis or other such purposes. Itshould be understood that there can be many other aspects that may needto be stored in the data store, such as for page image information andto access right information, which can be stored in any of the abovelisted mechanisms as appropriate or in additional mechanisms in the datastore 1910. The data store 1910 is operable, through logic associatedtherewith, to receive instructions from the application server 1908 andobtain, update or otherwise process data in response thereto. In oneexample, a user might submit a search request for a certain type ofitem. In this case, the data store might access the user information toverify the identity of the user, and can access the catalog detailinformation to obtain information about items of that type. Theinformation then can be returned to the user, such as in a resultslisting on a Web page that the user is able to view via a browser on theuser device 1902. Information for a particular item of interest can beviewed in a dedicated page or window of the browser.

Each server typically will include an operating system that providesexecutable program instructions for the general administration andoperation of that server, and typically will include a computer-readablestorage medium (e.g., a hard disk, random access memory, read onlymemory, etc.) storing instructions that, when executed by a processor ofthe server, allow the server to perform its intended functions. Suitableimplementations for the operating system and general functionality ofthe servers are known or commercially available, and are readilyimplemented by persons having ordinary skill in the art, particularly inlight of the disclosure herein. In some embodiments, an operating systemmay be configured in accordance with or validated under one or morevalidation regimes such as Evaluation Assurance Level (EAL) level 4.

The environment in one embodiment is a distributed computing environmentutilizing several computer systems and components that areinterconnected via communication links, using one or more computernetworks or direct connections. However, it will be appreciated by thoseof ordinary skill in the art that such a system could operate equallywell in a system having fewer or a greater number of components than areillustrated in FIG. 19. Thus, the depiction of the system 1900 in FIG.19 should be taken as being illustrative in nature, and not limiting tothe scope of the disclosure.

The various embodiments further can be implemented in a wide variety ofoperating environments, which in some cases can include one or more usercomputers, computing devices or processing devices which can be used tooperate any of a number of applications. User or client devices caninclude any of a number of general purpose personal computers, such asdesktop or laptop computers running a standard operating system, as wellas cellular, wireless and handheld devices running mobile software andcapable of supporting a number of networking and messaging protocols.Such a system also can include a number of workstations running any of avariety of commercially-available operating systems and other knownapplications for purposes such as development and database management.These devices also can include other electronic devices, such as dummyterminals, thin-clients, gaming systems and other devices capable ofcommunicating via a network.

Most embodiments utilize at least one network that would be familiar tothose skilled in the art for supporting communications using any of avariety of commercially-available models and protocols, such asTransmission Control Protocol/Internet Protocol (“TCP/IP”), Open SystemInterconnection (“OSI”), File Transfer Protocol (“FTP”), Universal Plugand Play (“UpnP”), Network File System (“NFS”), Common Internet FileSystem (“CIFS”) and AppleTalk. The network can be, for example, a localarea network, a wide-area network, a virtual private network, theInternet, an intranet, an extranet, a public switched telephone network,an infrared network, a wireless network and any combination thereof.

In embodiments utilizing a Web server, the Web server can run any of avariety of server or mid-tier applications, including Hypertext TransferProtocol (“HTTP”) servers, FTP servers, Common Gateway Interface (“CGI”)servers, data servers, Java servers and business application servers.The server(s) also may be capable of executing programs or scripts inresponse requests from user devices, such as by executing one or moreWeb applications that may be implemented as one or more scripts orprograms written in any programming language, such as Java®, C, C# orC++, or any scripting language, such as Perl, Python or TCL, as well ascombinations thereof. The server(s) may also include database servers,including without limitation those commercially available from Oracle®,Microsoft®, Sybase® and IBM®.

The environment can include a variety of data stores and other memoryand storage media as discussed above. These can reside in a variety oflocations, such as on a storage medium local to (and/or resident in) oneor more of the computers or remote from any or all of the computersacross the network. In a particular set of embodiments, the informationmay reside in a storage-area network (“SAN”) familiar to those skilledin the art. Similarly, any necessary files for performing the functionsattributed to the computers, servers or other network devices may bestored locally and/or remotely, as appropriate. Where a system includescomputerized devices, each such device can include hardware elementsthat may be electrically coupled via a bus, the elements including, forexample, at least one central processing unit (“CPU”), at least oneinput device (e.g., a mouse, keyboard, controller, touch screen orkeypad), and at least one output device (e.g., a display device, printeror speaker). Such a system may also include one or more storage devices,such as disk drives, optical storage devices, and solid-state storagedevices such as random access memory (“RAM”) or read-only memory(“ROM”), as well as removable media devices, memory cards, flash cards,etc. Various embodiments of the present disclosure may also beimplemented using custom hardware including, but not limited, customcryptographic processors, smart cards and/or hardware security modules.

Such devices also can include a computer-readable storage media reader,a communications device (e.g., a modem, a network card (wireless orwired), an infrared communication device, etc.) and working memory asdescribed above. The computer-readable storage media reader can beconnected with, or configured to receive, a computer-readable storagemedium, representing remote, local, fixed and/or removable storagedevices as well as storage media for temporarily and/or more permanentlycontaining, storing, transmitting and retrieving computer-readableinformation. The system and various devices also typically will includea number of software applications, modules, services or other elementslocated within at least one working memory device, including anoperating system and application programs, such as a client applicationor Web browser. It should be appreciated that alternate embodiments mayhave numerous variations from that described above. For example,customized hardware might also be used and/or particular elements mightbe implemented in hardware, software (including portable software, suchas applets) or both. Further, connection to other computing devices suchas network input/output devices may be employed.

Storage media and computer readable media for containing code, orportions of code, can include any appropriate media known or used in theart, including storage media and communication media, such as but notlimited to volatile and non-volatile, removable and non-removable mediaimplemented in any method or technology for storage and/or transmissionof information such as computer readable instructions, data structures,program modules or other data, including RAM, ROM, Electrically ErasableProgrammable Read-Only Memory (“EEPROM”), flash memory or other memorytechnology, Compact Disc Read-Only Memory (“CD-ROM”), digital versatiledisk (DVD) or other optical storage, magnetic cassettes, magnetic tape,magnetic disk storage or other magnetic storage devices or any othermedium which can be used to store the desired information and which canbe accessed by the a system device. Based on the disclosure andteachings provided herein, a person of ordinary skill in the art willappreciate other ways and/or methods to implement the variousembodiments.

The specification and drawings are, accordingly, to be regarded in anillustrative rather than a restrictive sense. It will, however, beevident that various modifications and changes may be made thereuntowithout departing from the broader spirit and scope of the invention asset forth in the claims.

Other variations are within the spirit of the present disclosure. Thus,while the disclosed techniques are susceptible to various modificationsand alternative constructions, certain illustrated embodiments thereofare shown in the drawings and have been described above in detail. Itshould be understood, however, that there is no intention to limit theinvention to the specific form or forms disclosed, but on the contrary,the intention is to cover all modifications, alternative constructionsand equivalents falling within the spirit and scope of the invention, asdefined in the appended claims.

The use of the terms “a” and “an” and “the” and similar referents in thecontext of describing the disclosed embodiments (especially in thecontext of the following claims) are to be construed to cover both thesingular and the plural, unless otherwise indicated herein or clearlycontradicted by context. The terms “comprising,” “having,” “including,”and “containing” are to be construed as open-ended terms (i.e., meaning“including, but not limited to,”) unless otherwise noted. The term“connected” is to be construed as partly or wholly contained within,attached to, or joined together, even if there is something intervening.Recitation of ranges of values herein are merely intended to serve as ashorthand method of referring individually to each separate valuefalling within the range, unless otherwise indicated herein, and eachseparate value is incorporated into the specification as if it wereindividually recited herein. All methods described herein can beperformed in any suitable order unless otherwise indicated herein orotherwise clearly contradicted by context. The use of any and allexamples, or exemplary language (e.g., “such as”) provided herein, isintended merely to better illuminate embodiments of the invention anddoes not pose a limitation on the scope of the invention unlessotherwise claimed. No language in the specification should be construedas indicating any non-claimed element as essential to the practice ofthe invention.

Preferred embodiments of this disclosure are described herein, includingthe best mode known to the inventors for carrying out the invention.Variations of those preferred embodiments may become apparent to thoseof ordinary skill in the art upon reading the foregoing description. Theinventors expect skilled artisans to employ such variations asappropriate, and the inventors intend for the invention to be practicedotherwise than as specifically described herein. Accordingly, thisinvention includes all modifications and equivalents of the subjectmatter recited in the claims appended hereto as permitted by applicablelaw. Moreover, any combination of the above-described elements in allpossible variations thereof is encompassed by the invention unlessotherwise indicated herein or otherwise clearly contradicted by context.

All references, including publications, patent applications and patents,cited herein are hereby incorporated by reference to the same extent asif each reference were individually and specifically indicated to beincorporated by reference and were set forth in its entirety herein.

What is claimed is:
 1. A computer-implemented method for providing datastorage services, comprising: receiving, from a customer deviceassociated with the computing resource service provider, informationrelated to a policy associated with a cryptography service, the policyincluding a limitation on cryptographic information generated by acryptography service of the computing resource service provider;processing the policy to cause the cryptography service to impose thelimitation on the cryptographic information; and causing thecryptography service to use, subject to the limitation, thecryptographic information to encrypt or decrypt the data such that thecryptographic information is only accessible to the cryptographyservice; and providing an outcome of the use of the cryptographicinformation.
 2. The computer-implemented method of claim 1, whereincausing the cryptography service to encrypt or decrypt the data isfurther subject to valid proof information that enables the cryptographyservice to verify authenticity of a received request to encrypt ordecrypt the data.
 3. The computer-implemented method of claim 1, whereinthe limitation includes a limitation on authorized requestors capable ofcausing the cryptography service to perform cryptographic operationsusing the cryptographic information.
 4. The computer-implemented methodof claim 1, wherein the limitation includes a limitation on a number ofuses of the cryptographic information.
 5. The computer-implementedmethod of claim 1, wherein the limitation includes a limitation on usingthe cryptographic information to decrypt or encrypt one or more types ofdata.
 6. A computer system, comprising: one or more processors; andmemory storing instructions executable by the one or more processors tocause the computer system to implement at least: a cryptography serviceconfigured to at least: process a policy related to a plurality of keys,the policy including one or more limitations on using the plurality ofkeys; store the plurality of keys such that the plurality of keys areinaccessible to a service different from the cryptography service;detect a pending request to process data; select, subject to the one ormore limitations, a key from the plurality of keys; process the datawith the selected key to perform one or more cryptographic operationsassociated with the pending request; and provide, to a requestorassociated with the request, an outcome associated with the use of theselected key.
 7. The computer system of claim 6, wherein detecting therequest includes receiving, from the service, a notification and proofof the request.
 8. The computer system of claim 6, wherein: the computersystem is operated by a computing resource service provider; the requestis generated by a customer device of a plurality of customer devices ofthe computing resource provider; and each key of the plurality of keysis associated with a different corresponding customer of the pluralityof customer devices.
 9. The computer system of claim 6, wherein thecryptography service is further configured to verify, against thepolicy, that the pending request is authorized.
 10. The computer systemof claim 6, further comprising a metering service configured to receiveoutput of the cryptography service and generate accounting records basedat least in part on the policy.
 11. The computer system of claim 6,wherein the cryptography service is further configured to enforce tleast one or more policies for each of at least a subset of theplurality of keys.
 12. The computer system of claim 11, wherein: thecomputer system is operated by a computing resource service provider;each key of the plurality of keys corresponds to a customer of thecomputing resource provider; and the cryptography service is furtherconfigured to: receive, from customers of the computing resourceprovider, policy updates; and update the stored policy informationaccording to the received policy updates.
 13. A computer-readablestorage medium having stored thereon instructions that, when executed byone or more processors of a computer system, cause the computer systemto at least: process a policy related to operation of a cryptographyservice, the policy defining one or more limitations on cryptographicoperations performed by the cryptography service; receive a request toutilize a service separate from the cryptography service; cause thecryptography service to use a key to perform, subject to the one or morelimitations, one or more cryptographic operations on information that,after the one or more cryptographic operations have been performed, isusable to fulfill the request, the key being inaccessible to theservice; and fulfill the request to utilize the service using theinformation.
 14. The computer-readable storage medium of claim 13,wherein the request includes an attestation that enables thecryptography service to verify, against the policy, that the request toutilize the service is authentic.
 15. The computer-readable storagemedium of claim 13, wherein: the request to utilize the service includesa request to perform an operation in connection with a data object; andthe information is a key used to encrypt the data object.
 16. Thecomputer-readable storage medium of claim 13, wherein the instructions,when executed by the one or more processors, further cause the computersystem to enforce a plurality of policies that includes the policy. 17.The computer-readable storage medium of claim 13, wherein the request toutilize the service is a request to perform a storage operation inconnection with a data object.
 18. The computer-readable storage mediumof claim 13, wherein causing the cryptography service to use the key toperform one or more cryptographic operations includes providing anidentifier of the key to enable the cryptography service to select thekey from a plurality of keys stored by the cryptography service, theidentifier being provided based at least in part on the one or morelimitations.
 19. The computer-readable storage medium of claim 13,wherein the instructions, when executed by the one or more processors,further cause the computer system to receive, from a customer deviceassociated with the computer system, a request to update the policy. 20.The computer-readable storage medium of claim 19, wherein the request toupdate the policy is received via an application programming interfaceprovided by the computer system.